1. Field of the Invention
The invention relates to a system and method which enable a data/video server to modify the bandwidth provided to one or more I/O (input/output) access channels coupled thereto. In particular, the invention relates a system and method which enable a data/video server to implement operation in accordance with a new connection diagram so that bandwidth requirement changes of one or more I/O access channels coupled thereto can be satisfied, and a data/video server including that system.
2. Description of the Related Art
Data/video servers such as the Media Pool video server developed by Philips Broadcast Television Systems Company (a division of Philips Electronics North America Corporation) contain a plurality of I/O (input/output) access channel connectors, a commutator and a plurality of storage arrays (each containing a plurality of disc drives therein) for use in storing and/or retrieving data from and/or to, respectively, one or more I/O access channels coupled to the I/O access channel connectors. The Media Pool video server, in particular, operates, via a control system (also contained therein), in accordance with the following rules of operation:
(1) Each individual I/O access channel connector is connected, via the commutator, to each of the storage arrays individually once in some sequence during a time period associated therewith, during which time period there may be one or more sub-periods in which that I/O access channel connector is not connected to a storage array (such connection of an I/O access channel connector to each of the storage arrays during such a time period is hereinafter referred to as a "CTA", i.e., connect-to-all). More particularly, each individual I/O access channel connector is connected, via the commutator, to each of the storage arrays individually once in a specific predetermined pattern (which is the same for all of the I/O access channel connectors) during a constant time period T.sub.b associated therewith, during which time period T.sub.b that I/O access channel connector is always connected to one of the storage arrays (such connection of an I/O access channel connector to each of the storage arrays during such a time period T.sub.b is hereinafter referred to as a "BLAST", which is sub-class of a CTA in which the pattern of connection is in accordance with a predetermined order and there are no sub-periods during that time period T.sub.b in which an I/O access channel connector associated therewith is not connected to a storage array. (Examples of CTAs and BLASTs are shown and discussed below in conjunction with FIG. 3.) PA1 (2) Multiple I/O access channel connectors can be connected to multiple storage arrays at a time, but during that time only one of the I/O access channel connectors can be connected to a given one of the storage arrays, and only one of the storage arrays can be connected to a given one of the I/O access channel connectors. PA1 (3) All of the I/O access channel connectors are individually connected to all of the storage arrays individually once during a constant time period T.sub.a.
This manner of operation allows the I/O access channels coupled to a Media Pool video server to substantially simultaneously provide data for storage in the storage arrays, receive the same (or different) data from the storage arrays or a combination of both.
The initial Media Pool video server was a symmetrical server, i.e., it contained the same number of I/O access channel connectors and storage arrays. Its manner of operation included having, at all times, each of the I/O access channel connectors (a) connected to a different one of the storage arrays and (b) continuously involved in performing BLASTs. This, in turn, meant that during each successive non-overlapping time period T.sub.a =T.sub.b, associated with any one of the I/O access channel connectors, each of the I/O access channel connectors was individually connected to each of the storage arrays individually once in the same pattern. For a more detailed discussion of the initial (symmetrical) Media Pool video server, reference is made to U.S. Pat. No. 5,539,660 and U.S. application Ser. No. 08/389,672, filed Feb. 16, 1995, which are incorporated herein by reference.
Although the initial Media Pool video server optimized the usage of the I/O access channel connectors and the storage arrays (by always having each of the I/O access channel connectors connected to a different one of the storage arrays and involved in performing BLASTs), it failed to allow the bandwidth of the I/O access channels coupled to the I/O access channel connectors to be different. On the contrary, because of its manner of operation, the bandwidth of each of the I/O access channels coupled to the I/O access channel connectors of the initial Media Pool video server was the same.
This problem, however, has be solved by the introduction of a newer current Media Pool video server which can operate as an asymmetrical server, i.e., it can contain a different number of I/O access channel connectors and storage arrays. (It should be noted that the current Media Pool video server can also be operated as a symmetrical server as well, but it employs the operating mechanism discussed in the next paragraph.) Like the initial Media Pool video server, the current Media Pool video server also follows the above-mentioned rules of operation. However, because it is not possible in all cases for each of the I/O access channel connectors of an asymmetrical Media Pool video server to be connected to a different one of the storage arrays all of the time or to always be continuously involved in performing BLASTs, as was the case with the initial Media Pool video server, an operating mechanism was introduced which not only enables the current Media Pool video server to follow the above-mentioned rules, but also enables it to provide different bandwidth to different ones of the I/O access channels coupled thereto.
The operating mechanism by which the current Media Pool video server achieves the above is by operating the server during successive cycles, each having a time period T.sub.s (.gtoreq.T.sub.a) (and hereinafter referred to as a supercycle"), in which in each supercycle each of the I/O access channel connectors is connected, via performing one or more CTAs (and to the extent possible, BLASTs), to each of the storage arrays for a sufficient amount of time so that each of the I/O access channels coupled to the I/O access channel connectors is provided with a sufficient amount of bandwidth to meet its needs during that supercycle. By operating in accordance with this mechanism, the current Media Pool video server can be programmed to operate in a manner whereby it provides different I/O access channels coupled thereto with different bandwidth. For a detailed description of this operating mechanism and an asymmetrical Media Pool video server, reference is made to the above-mentioned U.S. application Ser. No. 08/389,672 (see in particular FIGS. 11 and 12 and the discussion associated therewith).
Prior to the invention disclosed herein, it was believed that a current Media Pool video server needed to be programmed, prior to being brought on-line, i.e., booted-up, so that it would operate continuously in exactly the same manner supercycle after supercycle, i.e., in a static manner, until taken off-line. Furthermore, it was believed that when such a server was programmed, it had to be programmed, not only so that it would operate in a manner whereby it provides each of the I/O access channels with sufficient access, via the I/O access channel connectors, to the storage arrays during a supercycle to satisfy its bandwidth needs, but also, so that it would maximize the interconnections, via CTAs (and to the extent possible, BLASTs), of the I/O access channels connectors and storage arrays during that supercycle and leave little if any potential bandwidth unused during that supercycle. (Such a programming configuration can be represented by a connection diagram showing the number and placement of the CTAs and BLASTs performed by each of the I/O access channel connectors across the storage arrays during a supercycle. An example of such a diagram can be found in FIG. 12 of the above-mentioned U.S. application Ser. No. 08/389,672.)
The above-described static manner of operation of a current Media Pool video server and/or its operational programming to utilize substantially all of the potentially available bandwidth during a supercycle would have made it impossible for it to adapt to situations where the bandwidth needs of one or more of the I/O access channels coupled thereto change over time, e.g., when new or different applications are to be run, without having to be taken off-line and reconfigured. Shutting down a current Media Pool video server, reconfiguring it and then bringing it back on-line, i.e., rebooting it, to meet changing bandwidth needs of one or more of the I/O access channels coupled thereto is impractical, and in some situations unthinkable.
Accordingly, prior to the invention disclosed herein, there was a need to be able to change the operational programming configuration of the current Media Pool video server while on-line. Furthermore, it was realized that any such operational programming configuration change(s) would need to be done in a manner which would enable the current Media Pool video server to continue to operate properly during and after such operational programming configuration change(s).